Enterprise information technology (IT) has become increasingly complex, expensive and difficult to modify to support a company's changing requirements. With tightening budgets, businesses have begun to look for alternative options to IT to address these evolving requirements, including options provided by cloud services.
The term “cloud services” is a term used to describe IT applications that can be accessed ‘on demand’ from an external provider that hosts the application and provides a comprehensive set of support services to all users of these hosted applications. Cloud services have become increasingly popular since they can be quickly and easily deployed/used and because they are generally less expensive to use compared to on-premise, licensed software applications. Cloud services include IT solutions such as applications for customer relation management (CRM) payroll, email, enterprise resource planning (ERP), document management, and e-commerce from companies such as Netsuite, Salesforce, Google, and Amazon.
Widespread use of cloud services, however, is limited by at least two major technical challenges: integrating cloud-based applications with on-premise applications and creating/customizing pre-built applications rapidly for end customer use.
Integration of cloud-based applications with on-premise applications (defined as a real-time, synchronous and asynchronous connection and bi-directional communication between two applications) requires access to ERP applications, database servers and other on-premise systems. Cloud service to enterprise on-premise system integration also requires a secure network connection, which typically entails either the opening of additional ports (resulting in greater risk from external hackers due to the additional exposure and violation of the security compliance requirements of most companies), or creation of a VPN tunnel. Each of these approaches is relatively expensive and commercially not viable. In legacy ERP systems, for example, providing VPN connections may require substantial changes to the system's existing security architecture. For the cloud provider, a VPN approach would also undesirably require providing a VPN connection to each customer, which is not scalable.
There is currently no way to integrate a cloud application with an on-premise applications using a persistent connection without opening additional ports and/or using VPN. In FIG. 1, for example, a system is illustrated in which a cloud provider system connects to an ERP system via either a single port or VPN. For such system, data synchronization programs (Informatica, FTP, EDI, others) do not provide true application-to-application integration since they simply focus on ensuring that two data sources (e.g., databases, files, etc.) are synchronized. On-demand or on-premise integration software/appliances such as BOOMI, CASTIRON, and Netweaver also do not provide an adequate solution since these applications can only be used to facilitate data synchronization from an on-premise application from inside the firewall application (i.e., inapplicable to bi-directional realtime application-to-application integration).
Web services integration is also inadequate. Web services integration provides an open framework for two programs to publish services they offer using a web services directory. This framework, however, offers a request/response type connection (i.e., non-persistent) between two programs anywhere on a network and may require additional ports to be opened for use (See e.g., FIG. 1). Additionally, both the client and server programs would need a web services directory server, and new services must be created continuously as needed.
It should also be noted that integrating cloud services with on-premise applications would require a bidirectional communication model across a firewall. Within the enterprise firewall, Enterprise Java beans (EJB) provide a framework for remote object invocation, but such approach requires that both applications in the session be running within the firewall owing to its reliance on non standard RMI ports. Also, EJB requires complex configuration and is designed for unidirectional client server object communication where the client may request/retrieve objects from the server with limited support for bidirectional object communication. Furthermore, EJBs requires multiple technology stacks to be installed and configured before any distributed object communication may occur.
The above-described are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with the state of the art and corresponding benefits of some of the various non-limiting embodiments may become further apparent upon review of the following detailed description.